Skip to content

SE-0492: Metatypes and existential metatypes #85139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

SE-0492: Metatypes and existential metatypes #85139

wants to merge 1 commit into from
+213 −12

Conversation

@kubamracek
Copy link
Contributor

@kubamracek kubamracek commented Oct 26, 2025 •
edited
Loading

SE-0492 declared that constant expressions should support metatypes (of non-generic, non-resilient types). This adds support for using metatypes (T.self) and existential metatypes (upcasts to Any.Type, etc.) as static initializers for global variables, including those with @section attributes.

Major parts:

  • OptUtils.swift now allows MetatypeInst and InitExistentialMetatypeInst as valid static initializers for non-generic, non-resilient types.
  • IRGen now constant folds MetatypeInst and InitExistentialMetatypeInst
  • LegalConstExprVerifier now allows metatype erasure expressions

@kubamracek kubamracek requested a review from DougGregor October 26, 2025 05:04
DougGregor
DougGregor approved these changes Oct 31, 2025
View reviewed changes
Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This approach looks reasonable to me. I do really like having this feature, but it's a reasonable basis for any kind of "type registry" in the language

eeckstein
eeckstein reviewed Nov 3, 2025
View reviewed changes
test/ConstValues/SectionIR.swift
@section("mysection") let metatype2: Any.Type = Int.self
@section("mysection") let metatype3: Any.Type = S.self
@section("mysection") let metatype4: any (Hashable & Sendable).Type = Int.self
@section("mysection") let metatype5: any (Hashable & Sendable).Type = S.self
Copy link
Contributor

@eeckstein eeckstein Nov 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add tests for bound generic types, e.g. Array<Int>.self?

Copy link
Contributor Author

@kubamracek kubamracek Nov 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're rejecting that case syntactically: https://github.com/swiftlang/swift/pull/85139/files#diff-ea7de05f211d676ea604c35f0e6b253fb4a454efbfcc84928a931bab113e7bdcR82

Copy link
Contributor Author

@kubamracek kubamracek Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...but I did add that as a SIL test into test/SILOptimizer/static_init_metatypes.swift.

@kubamracek kubamracek changed the title [WIP] SE-0492: Metatypes and existential metatypes SE-0492: Metatypes and existential metatypes Nov 4, 2025
@kubamracek kubamracek marked this pull request as ready for review November 4, 2025 19:18
@kubamracek
Copy link
Contributor Author

kubamracek commented Nov 4, 2025

@swift-ci please test

@kubamracek
Copy link
Contributor Author

kubamracek commented Nov 4, 2025

And to point out explicitly: The OptUtils.swift and IRGen changes now cause MetatypeInst and InitExistentialMetatypeInst to be constant folded and statically initialized even outside of @section-annotated globals. Is that reasonable, @eeckstein ?

eeckstein
eeckstein reviewed Nov 5, 2025
View reviewed changes
test/SILOptimizer/static_init_metatypes.swift
@@ -0,0 +1,57 @@
// RUN: %target-swift-frontend %s -parse-as-library -module-name=test -emit-sil | %FileCheck %s
// RUN: %target-swift-frontend %s -parse-as-library -O -module-name=test -emit-sil | %FileCheck %s
Copy link
Contributor

@eeckstein eeckstein Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also add a -emit-ir invocation to make sure that IRGen can deal with this.

Copy link
Contributor

@eeckstein eeckstein Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that reasonable

Yes, that should be fine. As long as IRGen can handle those SIL initializer instructions.

@kubamracek
Copy link
Contributor Author

kubamracek commented Nov 5, 2025 •
edited
Loading

https://ci.swift.org/job/swift-PR-macos/25548/console

[2025-11-04T22:52:04.921Z]   Swift(macosx-x86_64) :: Macros/macro_expand_extensions.swift

[2025-11-04T22:21:00.600Z] Undefined symbols for architecture x86_64:
[2025-11-04T22:21:00.600Z]   "_$s9MacroUser16TestAvailabilityVSQAAWP", referenced from:
[2025-11-04T22:21:00.600Z]       _$s9MacroUser16TestAvailabilityV1xSQ_pXpvpZ in macro_expand_extensions-787e4c.o

https://ci.swift.org/job/swift-PR-Linux/24711/console

12:43:31    Swift(linux-x86_64) :: Macros/macro_expand_extensions.swift

[2025-11-04T20:35:31.651Z] /tmp/lit-tmp-39x03tfx/macro_expand_extensions-e4e00b.o:macro_expand_extensions-e4e00b.o:$s9MacroUser16TestAvailabilityV1xSQ_pXpvpZ: error: undefined reference to '$s9MacroUser16TestAvailabilityVSQAAWP'

https://ci-external.swift.org/job/swift-PR-windows/47464/console

   Creating library lib\SWBProtocol.lib and object lib\SWBProtocol.exp
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol21AppleScriptBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol19CopyFilesBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol20FrameworksBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol17HeadersBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol21JavaArchiveBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol19ResourcesBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol13RezBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol21ShellScriptBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP

BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol17SourcesBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP

bin\SWBProtocol.dll : fatal error LNK1120: 9 unresolved externals

I think those are all real issues caused by the new constant folding actually adding these referencing to the witness tables. @eeckstein any ideas here?

@eeckstein
Copy link
Contributor

eeckstein commented Nov 5, 2025

Difficult to say without looking at the generated llvm ir. Maybe it's a problem if the referenced type is defined in a different module

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@eeckstein eeckstein eeckstein left review comments

@DougGregor DougGregor DougGregor approved these changes

@hborla hborla Awaiting requested review from hborla hborla is a code owner

@slavapestov slavapestov Awaiting requested review from slavapestov slavapestov is a code owner

@xedin xedin Awaiting requested review from xedin xedin is a code owner

@jckarter jckarter Awaiting requested review from jckarter jckarter is a code owner

@rjmccall rjmccall Awaiting requested review from rjmccall rjmccall is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@kubamracek @eeckstein @DougGregor